Extensible Markup Language (XML) provides a way to represent data in a portable, vendor-neutral, human-readable format. The XML specification was defined by the World Wide Web Consortium (W3C) to establish the syntax and semantics of a tag-based language that allows a flexible format for hierarchical information. XML is a pared-down version of the Standard Generalized Markup Language (SGML), a system for organizing and tagging elements of a document. XML is particularly useful for Web documents, and is a metalanguage that essentially is a language for describing other languages. It allows designers to create their own customized tags, enabling the definition, transmission, validation, and interpretation of data between applications and between organizations. For further description of XML, see e.g., “Extensible Markup Language (XML) 1.0”, (2nd Edition, Oct. 6, 2000) a recommended specification from the W3C, the disclosure of which is hereby incorporated by reference. XML has become the preferred format for transferring information between computers particularly as web services.
With respect to accessing XML from an imperative programming language, the W3C defined the Document Object Model (DOM) to facilitate the parsing of XML documents. The DOM is an application programmer's interface to XML data and is available from many programming languages, including Java and JavaScript (also called ECMAScript). The programs access XML data via the tree-like DOM API, and the XML parsers produce a DOM representation of an XML document.
XPath is a separate W3C specification for addressing parts of an XML document. XPath includes a query-like capability for retrieving XML nodes and testing for the existence of document structures and data elements.
There are various specifications that dictate the limitations of general XML with respect to a specific purpose. These are referred to as XML dialects.
Simple Object Access Protocol (SOAP) is a relevant example of a specification and XML dialect for framing XML messages sent between computer processes. SOAP separates the application specific message content from other aspects of message communications like security, addressing or reliability by defining a Body section and a Headers section, respectively. Application developer's focus on application messages and vendor supplied systems can provide the infrastructure parts.
Web Services Description Language (WSDL) as used herein, includes an XML format for describing network services (often web services) as a set of endpoints operating on messages containing either document-oriented or procedure-oriented information. The operations and messages are described abstractly, and then bound to a concrete network protocol and message format to define an endpoint. Related concrete endpoints are combined into abstract endpoints (services).
WSDL is a specification and XML dialect for describing the operations a service provides including how input and output messages are formed. The specific format of the XML messages is defined using a combination of WSDL and XML Schema (XSD). XSD is a specification and XML dialect for describing the type of XML instance documents, in this case XML SOAP message parts. WSDL is extensible to allow description of endpoints and their messages regardless of what message formats or network protocols are used to communicate.
A WSDL description conveys the service's published interface contract. It is frequently made up of many interconnecting WSDL and XSD documents. The complete set of documents describes the service operations and the data types the service expects to use to communicate. The service contract can be difficult to understand in its entirety since WSDL and XSD documents are often built independently by different people or organizations.
These various XML dialects were developed separately for independent purposes and later adapted to current web services stacks. These technologies compose together in ways the individual designers did not define completely so the context of the composite system is different than that originally envisioned by the specification authors. This results in a set of specifications that are sometimes ambiguous, sometimes redundant and often confusing for application developers.
XML, SOAP, WSDL and XSD comprise the core set of specifications used to build and manage XML web services. Web services provide functionality to clients on a computer network. The software readily available for common programming languages and runtime environments, collectively known as a “SOAP stack”, provides the messaging capabilities to the application programmer. SOAP stacks are implemented to the specifications and have latent interoperability problems due to ambiguity and the interpretation of the vendor.
The promise of XML web services is to decouple the implementation choices of the server and the client. By agreeing on a standardized, text based communications mechanism, programs on different operating systems at different locations can communicate and change independently. This so called “loose coupling” allows IT systems to evolve more naturally by minimizing what clients and services need to know about one another. SOAP stacks with incompatible assumptions or implemented subsets of the core specifications create interoperability problems. By restricting or qualifying usage of concepts in the WSDL and XSD documents of a service's contract, service implementers can avoid common interoperability problems.
Best Practices are further constraints that a corporation might incorporate into guidelines to improve system quality and increase system development efficiency. The practices focus on constraining and qualifying the use of elements in the core web services specifications. An area of best practice focus is in constraining the WSDL and XSD constructs used so XML messages can be mapped effectively into a wide variety of programming languages. Mapping technologies vary among languages and environments due to the challenges of mapping XML to a language's native data structures. By avoiding aspects of WSDL and XSD these mapping problems are avoided. By applying best practices the mapping can lead to a clean and maintainable API for application developers.
In order to promote more consistent interpretation of the Web service specifications, the Web Services Interoperability Organization (WS-I) was formed to promulgate specific guidelines and recommended practices for using and developing Web services. The WS-I provided the Basic Profile (BP) to address known interoperability issues and is predominantly a restriction of the original WSDL 1.1 specification to the most interoperable practices. However, even within the WS-I, at present there has been no absolute consensus of interoperability and the formulation to ensure the Web services were indeed interoperable. The WS-I has limited its focus to initial areas of inquiry, most notably, ignoring XSD entirely.
While there are many toolkits to help automate the design process of Web services, not all the toolkits behave in the same way, and this leads to a wide range of interoperability problems. In current practice, the entire development team must be integrally involved to ensure that the service is compatible with other interoperable toolkits. The Developer needs to have interoperability concerns in mind from the beginning of the development cycle throughout the entire design and implementation. The Project Manager needs to make it a policy to test for interoperability as part of the quality of their service. And the Tester has to continually check the quality of the service once in operation. Interoperability has become such a major component to the quality of a Web service, it is absolutely necessary to have tools to help detect and solve interoperability problems when they arise.
In theory, interoperability requires an infinite amount of testing under all possible circumstances. However, in practice, the service is continually monitored and any breakage is repaired and the fix becomes part of the regression tests thereby improving the testing process. The WS-I established a suite of test tools that check a Web service's message exchanges and WSDL against the assertions in the BP. The test tools are essentially passive and require the tester to invoke the service manually, capture the SOAP messages off the wire, and log them in the WS-I's log format. Using the tools effectively is not an easy task and the output of their analysis is a large, flat report. The report serves as an indicator of a service that has failed, but using the report to determine exactly what went wrong and how to begin fixing the problem is difficult and tedious.
There are typically two time frames that one can check for conformance: design-time and run-time. Design-time is when the XML documents are first being written, and they are checked for conformance before they are put out for wide release. Run-time is checking XML messages coming to and from a service to make sure that they conform both to specification and to the WSDL document.
What is needed is a system for checking XML applications for conformity of the underlying specification. The diagnosis should be followed-up with the simple and easily navigable interface that displays the results in an intelligible fashion that facilitates any required analysis.